| Oracle® OPatch User's Guide Release 12.1 for Windows and UNIX Part Number E39376-01 |
|
|
PDF · Mobi · ePub |
| Oracle® OPatch User's Guide Release 12.1 for Windows and UNIX Part Number E39376-01 |
|
|
PDF · Mobi · ePub |
OPatch is a utility that allows you to apply and/or roll back interim patches to Oracle's software. The manual process of applying a patch is called binary patching. For bits patching, you can use the OPatch utility to:
Note:
Always refer to the patch README for any special instructions before you apply a patch.Oracle recommends that you back up the ORACLE_HOME before any patch operation. You can back up the ORACLE_HOME using your preferred method. You can use any method, such as zip, cp -r, tar, and cpio to compress the ORACLE_HOME.
You should use the version of OPatch that supports the ORACLE_HOME release. For example, if you are patching a 12.0.1 Oracle Home, then use OPatch version 12.0.1. If the Oracle Home is version 11.2 , then use OPatch version 11.2.
Oracle recommends that you use the latest released OPatch for 12.1 releases, which is available for download from My Oracle Support (patch 6880880). Select the ARU link for the 12.1.0.1.0 release.
https://updates.oracle.com/download/6880880.html
Before you use the OPatch command and available options, you must check that OPatch prerequisites have been fulfilled.
Using the OPatch utility to patch your GI/RAC/DB home typically consists of the following steps:
OPatch verifies whether the GI/RAC/DB home is present. You must ensure that the ORACLE_HOME environment variable is set to the GI/RAC/DB home of the product you are trying to patch. Check your respective vendor documentation for the details on how to set the environment variable.
Note:
Oracle Universal Installer binaries and inventories must be present in the home to be patched.Other environment variables used include:
OPATCH_DEBUG — Boolean setting that specifies the amount of logging OPatch should perform.
PATH — GI/RAC/DB home path information.
Note:
Adding $ORACLE_HOME/OPatch to the $PATH makes it more convenient to execute the OPatch commands from any directory.The next step is to determine what is already installed on your system. For this, you use the OPatch lsinventory command with either the patch or patch_id options.
For more information about this command, see
After you have determined that your system configuration is appropriate for the patches you wish to apply, it is advisable to view the operations OPatch will perform before performing the patch application to help determine whether all system prerequisites are met before applying the patch. For this, you use the OPatch -report option to print all patch application actions OPatch will perform without actually executing the actions.
For more information about the -report option, see
Once you have determined that the patch can be applied to your system successfully, you can now use OPatch to apply the patch. For this, you use the OPatch apply command.
For more information about this command, see
After you have applied the patch to your system, you should perform a final check to ensure all patches have been successfully applied. For this, you again use the OPatch lsinventory command with either the patch or patch_id options. For more information about this OPatch command, see
Once you have verified the prerequisite checks, use OPatch to apply a patch:
The OPatch utility is located in the $Oracle_Home/OPatch directory. You can run it with various commands and options. See Appendix A, "OPatch Syntax and Commands," for a complete list of command options available with OPatch.
You apply a single patch following the generic patching workflow discussed earlier:
Once you have downloaded the patch, you can apply it (step 5) using the following command:
# opatch apply <patch directory location>/<patch ID>
For example:
# opatch apply /tmp/patch/12345678
You can create a text file containing the location of all patches you need to apply. Use OPatch to reference the file and apply the patches:
Create the text file of the patch location. The entry should have each patch location on a separate line:
vi patches.txt /tmp/patchlocation1/12345678 /tmp/patchlocation2/12365478 /scratch/patchlocation3/32165487
Save your changes.
Apply the patches with OPatch:
# opatch napply -idFile <location of text file>
For example:
#opatch napply -idFile /tmp/patches/patches.txt
OPatch detects and reports any conflicts encountered when applying a patch with a previously applied patch. The patch application fails in case of conflicts. You can use the -force option of OPatch to override this failure. If you specify -force, the installer firsts rolls back any conflicting patches and then proceeds with the installation of the desired patch.
You may experience a bug conflict and might want to remove the conflicting patch. This process is known as patch rollback. During patch installation, OPatch saves copies of all the files that were replaced by the new patch before the new versions of these files are loaded, and stores them in $ORACLE_HOME/.patch_storage. These saved files are called rollback files and are key to making patch rollback possible. When you roll back a patch, these rollback files are restored to the system. If you have a complete understanding of the patch rollback process, you should only override the default behavior by using the -force flag. To roll back a patch, execute the following command:
$ OPatch/opatch rollback -id <Patch_ID>
A patch conflict occurs when multiple fixes in different patches touch the same files but have not been tested together as a single entity. OPatch and OPatchauto help you avoid these conflicts by identifying these conditions. When patch conflicts occur and you are unable to resolve them using documented support procedures, MOS then becomes the go-to source for technical assistance. Conflict resolution may entail filing a Service Request and obtaining a Merge Label Request (MLR) patch to overcome a patching issue. Once a solution has been found, you use OPatch to apply the fixed patch.
When working with patches, there are four scenarios you may encounter based on the content of the patch versus the condition of the GI/RAC/DB home.
The following table describes these four situations and suggested actions.
| GI/RAC/DB Home Versus Patch Content | Description | Action |
|---|---|---|
| GI/RAC/DB home > Patch | You have more bug fixes in the GI/RAC/DB home than the patch. You do not need to apply the patch. | Do Nothing |
| GI/RAC/DB home < Patch | You have fewer bug fixes in the GI/RAC/DB home than the patch. You should apply the patch. | Apply the Patch |
| GI/RAC/DB home = Patch | The GI/RAC/DB home and the patch have the same bug fixes. | Do Nothing |
| GI/RAC/DB home and Patch Intersect | Under certain circumstances, the decision to apply the patch may not be clear, as would be the case where there are overlapping bug fixes: For example, you have bug fixes 1, 2 , 3 and 4 in the GI/RAC/DB home. The patch you want to apply contains bug fixes 3, 4, 5, and 6. In this situation, bug fixes 3 and 4 are in both the GI/RAC/DB home and the patch. If you install the patch, you will lose bug fixes 3 and 4. If you install the patch, you will loose some of the bug fixes. | Call Oracle Support or use the MOS patch plan feature to resolve the conflict. |
As shown above, all patches may not be compatible with one another. This is called a conflict situation. OPatch detects such situations and raises an error when a it detects a conflict. The following section illustrates in detail the patch/conflict states shown in the table.
OPatch can detect the following patch conflict conditions:
In this case, the GI/RAC/DB home already contains bug fixes in the patch in addition to other bug fixes.
Recommended Action: Do nothing.
Example
Consider the following scenario:
Patch A, installed in the GI/RAC/DB home, fixed bugs 1, 2, and 3.
Patch B, installed in the GI/RAC/DB home, fixed bugs 10, 11, and 12.
Patch D, to be installed, fixes bugs 1 and 2.
Patch D is a subset of Patch A.
Using the skip_subset Option
When you want to skip patches formerly applied in the GI/RAC/DB home that are now subsets of other patches you want to apply now, you can use the skip_subset option of napply. For example, if you used napply yesterday for patch A that fixed bugs 1 and 2, then you use napply today with the skip_subset option for patch B that fixes bug 1 and patch C that fixes bugs 1, 2, and 3. Then subset patch A is skipped, and patch C then becomes a superset of patch A.
The following example output shows the message you would see when you use the skip_subset flag:
$ OPatch/opatch napply /<path to patch>/ -id 100,101 -skip_duplicate -skip_subset
Oracle Interim Patch Installer version 11.1.0.9.10
Copyright (c) 2012, Oracle Corporation. All rights reserved.
Oracle Home : /<path to OH directory>/oraclehome/11.1.0.6/dbhome_1
Central Inventory : /<path to oraInventory directory>/oraInventory
from : /<path to OH directory>/oraclehome/11.1.0.6/dbhome_1//oraInst.loc
OPatch version : 11.1.0.9.10
OUI version : 11.1.0.7.0
Log file location : /<path to OH directory>/oraclehome/11.1.0.6/dbhome_1/cfgtoollogs/opatch/opatch2013-05-14_11-31-29AM_1.log
Verifying environment and performing prerequisite checks...
Conflicts/Supersets for each patch are:
Patch : 100
Bug SubSet of 101
Subset bugs are:
111
Patch : 101
Bug Superset of 100
Super set bugs are:
111Skip these patches because they are subset of other patches in the list: 100
Proceed with these patches: 101
Checking skip_duplicate
Checking skip_subset
OPatch found that the following patches are not required.
They are either subset of the patches in Oracle Home (or) subset of the patches in the given list
(or) duplicate :
100
OPatch continues with these patches: 101
Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.
Provide your email address to be informed of security issues, install and
initiate Oracle Configuration Manager. Easier for you if you use your My
Oracle Support Email address/User Name.
Visit http://www.oracle.com/support/policies.html for details.
Email address/User Name:
You have not provided an email address for notification of security issues.
Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]: Y
Backing up files...
Applying interim patch '101' to OH '/<path to OH directory>/oraclehome/11.1.0.6/dbhome_1'
Patching component oracle.rdbms.rsf, 11.1.0.7.0...
Verifying the update...
Patches 101 successfully applied.
OPatch Session completed with warnings.
Log file location: /<path to OH directory>/oraclehome/11.1.0.6/dbhome_1/cfgtoollogs/opatch/opatch2013-05-14_11-31-29AM_1.log
OPatch completed with warnings.
The expected behavior for the Apply and Napply commands is listed in Table 2-1.
Table 2-1 Expected Conflict Behavior
| Command | GI/RAC/DB home>Patch | GI/RAC/DB home<Patch | GI/RAC/DB home=Patch | GI/RAC/DB home Intersects Patch |
|---|---|---|---|---|
|
Apply |
OPatch performs an automatic rollback, then an apply. |
After the merge request, OPatch performs an automatic rollback, then performs an apply. |
OPatch performs an automatic rollback, then performs a reapply. |
OPatch reports the conflict. After the merge request, OPatch performs an automatic rollback, then an apply. |
|
Napply |
OPatch performs an automatic rollback, then an apply. |
OPatch reports the subset and skips the subset patch. It then continues and applies the other patches. |
OPatch performs an automatic rollback, then a reapply. |
OPatch reports the conflict, then asks you to run again without applying a bug conflict patch. You can use the -force option to instruct OPatch to automatically roll back the conflicting patch, then apply the new patch. |
In the case of napply, because multiple patches are being applied, patches may conflict with each other in the same way a patch and an GI/RAC/DB home conflict (OH>Patch, OH<Patch, OH=Patch, and OH intersects Patch). When patch/patch conflicts arise, the same recommended actions should be applied.
The following example applies all patches under the <patch_location> directory. OPatch skips duplicate patches and subset patches (patches under <patch_location> that are subsets of patches installed in the GI/RAC/DB home).
The following example applies patches 1, 2, and 3 that are under the <patch_location> directory. OPatch skips duplicate patches and subset patches (patches under <patch_location> that are subsets of patches installed in the GI/RAC/DB home).
If a patch contains bug fixes that contain have already been fixed in the GI/RAC/DB home plus additional bug fixes, then this patch is considered a superset of patches already applied to the GI/RAC/DB home. If a patch superset condition is detected, it is not considered an error situation: All the subset patches are removed from the system and the new patch is applied.
Recommended Action: Apply the patch.
Example
Consider the following scenario:
Patch A, installed in the GI/RAC/DB home, fixed bugs 1, 2, and 3.
Patch B, installed in the GI/RAC/DB home, fixed bugs 10, 11, and 12.
Patch C, to be installed, fixes bugs 1, 2, 3, and 4.
Patch C is considered a superset of Patch A.
Using the -no_bug_superset Flag
If you want OPatch to error out if the current patch bugs-to-fix is a superset or the same as an installed patch bugs-fixed in the GI/RAC/DB home directory, you can use the -no_bug_superset flag:
$ OPatch/opatch apply -no_bug_superset <Path_To_Patch>
The following example output shows the message you would see when you use the -no_bug_superset flag:
$ OPatch/opatch apply -no_bug_superset /<path_to_patch>/patch101_CP1/ Oracle Interim Patch Installer version 11.1.0.9.10 Copyright (c) 2012, Oracle Corporation. All rights reserved. Oracle Home : /<path to OH directory>/oraclehome/11.1.0.6/dbhome_1 Central Inventory : /<path to oraInventory directory>/oraInventory from : /<path to OH directory>/oraclehome/11.1.0.6/dbhome_1//oraInst.loc OPatch version : 11.1.0.9.10 OUI version : 11.1.0.7.0 Log file location : /<path to OH directory>/oraclehome/11.1.0.6/dbhome_1/cfgtoollogs/opatch/opatch2013-05-14_11-34-19AM_1.log Applying interim patch '101' to OH '/<path to OH directory>/oraclehome/11.1.0.6/dbhome_1' Verifying environment and performing prerequisite checks... Interim patch 101 is a superset of the patch(es) [ 100 ] in the Oracle Home OPatch system modification phase did not start: Interim patch 101 is a superset of the patch(es) [ 100 ] in OH /<path to OH directory>/oraclehome/11.1.0.6/dbhome_1 Log file location: /<path to OH directory>/oraclehome/11.1.0.6/dbhome_1/cfgtoollogs/opatch/opatch2013-05-14_11-34-19AM_1.log OPatch stopped on request.
In this case, a patch fixes the same set of bugs fixed by another patch. For example, if you applied Patch A that fixed bugs 1, 2 and 3, and now apply Patch B that also fixes bugs 1, 2 and 3, then Patch B is a duplicate of Patch A. A patch is always a duplicate of itself.
Using the skip_duplicate Option
If you specify this option, OPatch removes duplicate patches from the list of patches to be applied. For example, if you used napply yesterday for Patch A discussed above, then use napply today with the -skip_duplicate option for Patch A and other patches, duplicate Patch A is skipped.
In this case, a patch conflict condition exists whereby a set of bugs to be fixed by the current patch intersects with some bugs already fixed by one or more previously installed patches.
Recommended Action: Call Oracle Support. You may need to request an MLR patch.
Example
The following example illustrates this patch conflict condition during patch application. In the example, opatch apply fails with error code 56.
|
 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|